In legacy database installations, database and clusterware applications were distributed as product media (e.g., via CD/DVDs) that may include an installer application to extract the software bits from the product media and install the database and/or clusterware software, hereinafter referred to as the “database software” or “database”, onto a designated home directory. Users most often configure the database a few months after their initial purchase of the database such that a number of bug fixes and security patches may have been released in the form of Critical Patch Updates (CPUs), Patchset Security Updates (PSUs), Release Updates (RUs), or Bundle Patches (BPs), all of which are hereinafter referred to as “RUs”. RUs are typically released within a time frame such as, for example, quarterly or semi-annually. Database software releases are also typically released within a time frame such as, for example, semi-annually or annually. Users typically use an installer application to install the software and then download the relevant RU(s) to patch the installed software (e.g., via the home directory) with the downloaded RUs, and then proceed with the configuration of the database software. This legacy process was error prone and cumbersome because of the many manual process steps involved with installing the software and applying the patches. There were no permanent solutions to these issues.
To exacerbate the problem, if a particular user customized the database software, the particular user may run into specific software/database issues such as, for example, specific bugs that other users may never run into because of the type of customizations performed by the particular user. In these cases, the software vendor may provide a one-off patch update to fix the specific bug(s) for the particular user and possibly any other users who may have a similar issue/bug in their customized database software. These one-off patch updates are usually not included in the general release of the RU(s) and/or software releases because these one-off patch updates are specifically tailored to particular users that customized the software in a particular way. However, in some cases, it may be determined that some of these one-off patch updates should be incorporated into the general database software release in the form of either a RU or into the general release of the database software itself because although the original issue/bug were deemed to be specific to a particular user, it may be determined later that many other users are affected by similar issues/bugs that the one-off patch update may resolve for the general user base.
However, since the one-off patch updates are usually not incorporated into the general release of the database software or into any RUs, the user must maintain an inventory of the one-off patch updates applied to their specific installation of their database software. When new software releases are available from the software vendor, the user must pay close attention to the new RU releases to know how to manually create new gold images for deployment incorporating the new RUs and/or database software releases along with their inventory of the one-off patch updates. Future database software releases by the vendor may require the user to apply any new RUs to the future database software release, along with any one-off patch updates not incorporated into the new RUs. Maintenance of the list of one-off patch updates and knowing when to apply the one-off patch updates to future database software releases based on whether any of the one-off patch updates have been rolled into the future RUs or future database software releases themselves may become burdensome and very time consuming for each user.
Additionally, the legacy approach required a number of manual interventions with the user having to download the latest RUs available, apply the RUs on the software bits of the base release, double check/investigate if any of the one-off patch updates pertaining to the user has been included in any of the RU(s) and/or database software release, apply the one-off patch updates to the RU(s) and/or software bits of the base release, test the new installation, and then distribute the tested database software installation (e.g., a Gold Image) across their organizations for future use.
The pitfalls in the legacy approach were (1) different mechanisms were used to install the database software releases, RU(s) and/or the one or more one-off patch updates, causing huge inconsistencies (e.g., each database administrator (DBA) has their own script for automating the installation process); (2) DBAs need to monitor the RU releases, as an example, every quarter and build the gold images manually; (3) The existing deployments may have one-off patch updates which may conflict with the new RU, which requires investigation; (4) The one-off patch updates may already be included in a new RU, which also requires investigation; (5) Despite all care, the degree of confidence on the gold images manually created by each customer's DBA was not high; and (6) Home-grown automation scripts of users tend to break because of changing naming conventions provided by the vendor, and new requirements from one RU to another (e.g. new installation utility to be downloaded before a RU may be applied).
Therefore, there is a need for an improved approach to generate a gold image that addresses the above-described problems.